A lot of these no longer apply to new users, but may be of interest to people who have been running Linux/m68k for a while.
This is by no means an exhaustive list. If you have any suggestions for entries, please send them to me.
Note that system-specific questions are in separate sections of the FAQ; you should read this section and the one pertaining to your system (if there is one) before assuming your question isn't answered here. Also note that system requirements are covered earlier in the FAQ.
There is a wealth of Linux documentation out there for the original PC Linux which almost always applies to Linux/m68k. Check out the documentation at your favorite Linux FTP site.
Having said that, if you're using a proper distribution (Debian or Red Hat), you should have man pages for all executable files; file a bug report if the pages are missing.
To access a SCSI device, you need to know two things: where it is logically located on your SCSI chain and what type of device it is.
Where it is on the chain determines what order it will appear in on the device list. Note that the SCSI ID is what is used to determine location on the chain; this ID will normally be between 0 and 6 (but can be between 0 and 15 if you have an Ultra-Wide SCSI controller).
What type of device it is determines how it is addressed.
Some examples:
/dev/sda is the first SCSI fixed disk (hard drive or
removable hard drive) on the chain. /dev/sdb is the second
SCSI fixed disk. To access partitions on hard drives, you follow the
device name with the partition number (e.g. /dev/sda1 is the
first partition on /dev/sda); you can access up to 128 drives
and up to 15 partitions per drive.
/dev/scd0 is the first SCSI CD-ROM on the chain.
/dev/scd1 is the second SCSI CD-ROM. You can have up to 256
SCSI CD-ROM drives.
/dev/st0 is the first SCSI tape drive on the chain.
/dev/st1 is the second SCSI tape drive on the chain. You can
access up to 32 tape drives.
/dev/sg0 is the first miscellaneous ("generic") SCSI
device on the chain (most often this will be a scanner; it can also be a CD writer).
/dev/sg1 is the second generic SCSI device. You can have up
to 256 generic devices.
Note that to use an external SCSI device, it must be switched on when you boot the system. Also, it is a bad idea to swap removable fixed disks while the system is switched on (it is OK, however, to swap CD-ROMs and tapes, when they aren't mounted).
If you have multiple controllers, the device assignments will get horribly confusing (there is a logic to it, but it defied my powers of explanation); I recommend reading the boot messages to determine what device addresses are being assigned to each device.
Unlike the SCSI driver (which can distinguish between CD-ROMs, tape drives and fixed disks), the address of most devices on the IDE bus (except tape drives) only depends on where it appears to be on the bus. Assuming you have an IDE controller, all you need to know to access it is what "hard drive position" it appears in:
You can have more than two controllers: for example, hde and hdf correspond to the master and slave on the tertiary controller. You can currently have up to six IDE controllers on a system (and thus up to 12 drives).
This information should also appear in the boot messages. You can access up to 63 partitions on an IDE fixed disk. Note that the distinction between "primary" and "logical" partitions only applies to disks partitioned using the MS-DOS partitioning scheme.
Parallel IDE devices are currently not supported on any Linux/m68k system; however, the underlying hardware support is available on at least some Amiga IO cards.
Generally if you have just an IDE hard drive and an IDE CD-ROM, the
CD-ROM will be hdb (depending on your master/slave settings).
Simply make a mount point (e.g. mkdir /cdrom) and then do
mount -t iso9660 /dev/hd? /cdrom, replacing the ?
with the drive letter from the list above.
IDE tape drives are accessed through /dev/hdt0
(/dev/nhdt0 for no-rewind-on-close). Note that only one IDE
tape drive is supported.
(written by Frank Neumann)
Some devices dislike being polled on LUNs (logical units) other than
0. What can happen here is that the SCSI bus just locks up because the
device does not answer the inquiry. Quite a couple of drives have
already been added to the blacklist of "bad" devices in
the kernel, but there are probably more. If you discover this behavior
on one of your SCSI devices, you might try adding it to the blacklist
(in drivers/scsi/scsi.c) yourself or ask someone to do it for
you if you are sure about it.
If you think you're adventurous and want to fix the kernel for a specific SCSI device yourself, here is what you could do. Note that these instructions are for the Amiga, but they apply in general to all systems:
Under AmigaOS, use the scsiutil command (available on Aminet) and its
-i option to send an Inquiry command to that particular device. Write
down its vendor identification, product identification and Product revision
level. For instance, an Apple CD-300 CD-ROM drive might give (at the
bottom) this output:
Vendor identification: SONY
Product identification: CD-ROM CDU-8003A
Product revision level: 1.9a
Now go into the kernel source tree and (under drivers/scsi/scsi.c)
add your drive to the blacklist of drives that have problems (just search
for "blacklist"). Recompile the kernel and try it out without the wd33c93=
options you probably used so far.
If it works, you might want to send your change as a unified context diff (use "diff -u") to the Linux/m68k mailing list.
(written by Frank Neumann)
Once in a while, it may happen to you that you try to read a binary
file. Text viewers like more will interpret the input they get as
control characters, to for instance change to an alternate character
set. This may result in a strange looking prompt, made up of special
characters. In such a case, you need to reset the terminal to its
initial state. There are several ways to do this, here's what I use:
You have to type (blindly):
echo ^V^O
Read this as: Control-V, Control-O. The sequence "Control-O" does just what we want: It resets the text attributes and character set, and also clears the screen. You have to mask the control character with Control-V, otherwise the shell would directly try to use the "Control-O" for its purposes.
Control-V Esc c is another useful sequence that does a more complete reset of the console (but you usually won't need to use it).
You can also avoid this problem by using less or most
instead of more; both of these pagers are available in Debian.
Be sure to set up a PAGER environment variable (in your .cshrc or
.bashrc) so programs like man use your preferred pager instead.
(written by Frank Neumann and Jesper Skov)
No problem. If you moved to ELF according to Andreas Schwab's hints
(ftp://tsx-11.mit.edu/pub/linux/680x0/ELF/README), you
already have a mixed system. All old a.out shared libraries, stubs,
static libraries and simple object files (*.so, *.sa, *.o, *.a) are
now in /usr/m68k-linuxaout/lib, except for libc and libm
which remain in /lib. The ELF shared libraries are in the
usual places (/lib, /usr/lib and maybe
/usr/X11R6/lib and /usr/local/lib) and don't
interfere with the a.out libraries.
When starting a program that is either a.out or ELF, the corresponding link loader (ld.so and ld-linux.so respectively) will determine what shared libraries are required and load them on the fly. This of course works for both a.out and ELF binaries. You only have to keep in mind that with a mixed system (using some binaries that require ELF libraries along with others that require a.out libraries) both ELF and a.out libraries have to be kept in memory (in particular, but not limited to, libc and libm). This certainly costs valuable memory. So, the long-term solution will be a pure ELF installation (libraries and binaries).
You can download the ELF versions of the programs via FTP, download sources and recompile, or "Debianize" your system (I really don't recommend the latter unless you really know what you are doing).
If you install any recent distribution, you will have the a.out compatibility libraries but (hopefully) no a.out binaries.
Note: Concerning a.out libraries, a couple of people had problems with the last libc that was created (4.7.2). So we recommend staying with 4.6.27 which most people were using.
Note: a.out is effectively dead on Linux/m68k. You can probably live without a.out support (you might want it available as a module, however).
The older versions of the root-filesys have the wrong device numbers for
/dev/tty. Delete it and do a /dev/MAKEDEV std (you do have a
somewhat current /dev/MAKEDEV, don't you?)
The "official" version of MAKEDEV for Linux can be found at
http://metalab.unc.edu/pub/Linux/system/Admin/. A list of the
major/minor device numbers can also be found in the kernel tree as
Documentation/devices.txt.
Debian/m68k includes a MAKEDEV that is pre-configured for Linux/m68k.
Use the file command. It will either tell you 'mc68020 demand paged' if it
is an a.out binary, and give a longer (self-explanatory) description if it
is ELF.
You can also use ldd. If it says something about a "DLL
jump", the binary is in a.out format; otherwise, it's in ELF.
For statically linked binaries, ldd reports statically linked
(ELF) for ELF binaries. I have no idea what it says for a.out
binaries, because I don't have anything statically linked a.out any
more (at least, not that I can find).
(written by Geert Uytterhoeven)
The current ld requires you to create links from *.so to *.so.6 for
all libs, so you should have e.g. libX11.so -> libX11.so.6,
libX11.so.6 -> libX11.so.6.0
The development packages in Debian automatically handle this situation.
Please read Michael Schmitz's mini-HOWTO on this topic; it's available at http://www.linux-m68k.org/ext2swap.html. The mini-HOWTO also explains how to check if you need to do anything.
It is possible that you have an IDE controller on your system without any IDE devices attached to it. If you have been experiencing problems like this, you should upgrade to kernel 2.0.28. If upgrading doesn't fix the problem, ask for help in the newsgroup.
You need modutils-2.1.23 or later. Note that these modutils are incompatible with kernels from 2.1.0 to 2.1.17, so you'll need to keep a copy of modutils-2.1.13 around if you plan on switching back and forth. The sources for modutils can be found at ftp://ftp.redhat.com/pub/alphabits/ or a more reliable mirror, ftp://tsx-11.mit.edu/pub/linux/projects/alphabits/.
If you're running 2.1.26 or later, no patches should be necessary (beyond the ones you had to apply to get that version to compile).
Modules in 2.1 series kernels also require running libc 5.4.17 or later (which in turn requires ld.so 1.8.5 or later). In any event, you probably should be running glibc by now.
Current versions of modutils are available in Debian that support
both 2.0 and recent 2.1/2.2 kernels.
See Distributions for an answer to this question.
Once you have a copy of the Linux/m68k kernel, you should rarely need to get a completely new tree. Instead, you can patch the kernel sources to the next released version.
For example, if you have the 2.0.25 kernel tree already, you need to
get the file linux-2.0.28.diff.gz via FTP (don't get the file
with the word "native" in it unless you have the same
version kernel tree for Linux/i386). Then use cd to get to the
directory above your kernel tree (probably /usr/src), and
make a copy using hard links to save a lot of space:
cp -rl linux-2.0.25 linux-2.0.28
You may also want to change your symbolic link linux ->
linux-2.0.25 to point to the new tree:
ln -sf linux-2.0.28 linux
This way, your links in /usr/include don't have to be changed
every time you upgrade your kernel (i.e. you can link
/usr/include/linux -> /usr/src/linux/include/linux instead
of using the kernel version number hard-coded). Then, cd to
linux-2.0.28 and type the following 2 commands:
rm -rf include/asm
zcat (path of linux-2.0.28.diff.gz) | patch -p1 -s
If all goes well, it will work for a minute or two and then return you
to your shell's prompt. Make sure the patch applied correctly by
typing find . -name '*.rej'. If no filenames are listed,
everything worked perfectly.
Now do a make clean to delete all the backup .orig files
left by patch, and then do a normal make config, make dep
and finally make.
Once you've successfully made a copy of the new kernel, you can
safely delete the previous version's tree using rm -r.
Please note that you will often get rejected patches if you patch a kernel tree that you have already patched from the Linux/m68k mailing list (or from any other source). The easiest way to avoid this is to make a "clean" (i.e. distribution) kernel tree and another tree that you apply the patches from the mailing list to.
Miniproject: Someone with a bit of spare time might want to adapt
scripts/patch-kernel to understand Linux/m68k diffs. Your
fellow Linux/m68k users would be eternally grateful.
This is basically the same as patching a Linux/m68k kernel tree. At
sunsite.auc.dk, Jes maintains two sets of diffs for each
kernel version: they are named X.Y.Z.diff.gz and
X.Y.Z-native.gz, where X, Y and Z are the components of the
kernel version number.
Most users will simply use the standard patches to patch a previous version of Linux/m68k's tree to the current version (this is the procedure outlined above). If you already have a standard Linux source tree, however, it is easier to use the -native patches.
To do this you must have the exact, pristine kernel tree released by Linus for that version; i.e. to make Linux/m68k 2.1.127 you need Linux 2.1.127. You may need to patch your standard Linux source tree using Linus's patches to get it to a version that corresponds with a Linux/m68k release (not every kernel released by Linus is released by Jes).
Once you have identical version numbers, you should cd into
your kernel source tree and type the following two commands:
rm -rf include/asm
zcat (path of linux-X.Y.Z-native.diff.gz) | patch -p1 -s
Any errors will be reported on your screen. There may be errors patching the Makefile for some versions (because the SMP setting used to be in there), but these can usually be ignored safely (check the contents of the reject files). You should also make sure that the ARCH setting in the Makefile has not been overridden.
Recent models of the Jaz drive (with firmware version H.71 and later) are shipped in a so-called "write-verify" mode. This mode causes problems for operating systems (like Linux) that can't run Iomega's proprietary drivers.
I (Chris) have been in touch with Iomega tech support, and they provided me with the low-level commands that allegedly get the Jaz drive into the correct mode. However, the commands they provided don't seem to work (probably (ab)user error, knowing my level of SCSI programming knowledge).
In the meantime, the only thing to do is find a Mac or PC with a SCSI interface and use Iomega's Jaz Tools software to disable the write verify mode. This can also be done with a registered copy of Shapeshifter on the Amiga. On a PC, you will need to use the Windows version of Jaz Tools to disable write-verify (the DOS version of the tools won't do it).
More information about the Jaz drive and Linux (including the Jaz mini-HOWTO) can be found at Bob Willmot's Jaz-Linux information page.
This usually means that you are running a buggy version of getty.
The agetty and mingetty versions of getty are known not
to have this problem, so replace your current getty with one of
these. The getty version included in Debian/m68k will also work
correctly.
[It may not actually be a bug in getty. But replacing it seems to fix the problem.]
Older kernels with FPU emulation are available from ftp://ftp.nocrew.org/pub/linux/. The FPU emulation code used in those kernels was adapted from NetBSD, and has bugs originating from both the emulation code itself and the Linux interface to it. The emulation code does not support all transcendent functions and not all supported functions have full precision implemented. Use of this FPU emulation code is not supported, endorsed, or sanctioned by the kernel developers; please do not send them bug reports, complaints, or even patches to this code.
The reason why the old FPU emulation code is unsupported is that its license is incompatible with the GNU General Public License. The code is restricted under the terms of the Berkeley Source Distribution license, which requires that accompanying code and documentation recognize the contributions of the University of California to the software. While this may seem to be a trivial point, the GPL does not allow any restrictions beyond those in the GPL on how software linked to the GPL can be distributed.
A new effort to write an improved FPU emulator under a GPL-friendly license is in the works; it is planned that this emulator will be licensed so it can be used without any strings attached (probably under something like the MIT X license). If you are interested in helping with the coding (no testing yet), join the discussion on the Linux/m68k mailing list. When the FPU emulator is ready for testing, announcements will be made on the mailing list and in the newsgroups.
If you are interested in getting your hands dirty and doing some
actual work on the emulator, the code is at the Linux/m68k CVS
repository. The CVS server is cvs.linux-m68k.org; login with
user name "anon" and a blank password.
This is usually because of the initrd driver. Make sure you specify
on the boot line "-r <ramdisk-name> root=/dev/ram".
The other possibility is that you don't have enough RAM to boot from a RAM disk (you really need at least 6 MBs with recent kernels). In this case, it is possible to write the ramdisk's contents to a high density disk and try booting from this (but, of course, you do need a high density drive to do this). Ask in the newsgroup for help if you don't know how to do this on your own. Alternatively you may be able to get someone else to compile a smaller kernel image specifically for your system (which will save a lot of RAM).
As a security precaution, most systems come pre-configured to not include
the current directory in your path. The lazy way out is to add "." to
your path, but I strongly recommend against doing that (particularly if you
are running as root).
The right way to handle this situation is to preface the program name with "./". For example, type "./configure" instead of "configure".
This is done with the "video" boot parameter. For details on what
resolutions are supported, you'll want to read
Documentation/m68k/framebuffer.txt (in 2.1/2.2,
Documentation/fb/framebuffer.txt) and
Documentation/m68k/kernel-options.txt in the Linux/m68k
kernel source tree (the former document only appeared in 2.0.28).
You can also specify what font you want to use with the font
option to 'video'.
For example, to boot into 640x480x4 mode on an Amiga with a 31 kHz or
multiscan monitor, use video=vga.
I use video=font:PEARL8x8,vga on my Amiga 4000, for a very nice
80x60 text display.
The easiest way to fix this is to change the "Modes" line
in your /etc/XF86Config to read:
Modes "default"
Later on, you can get Geert Uytterhoeven's fbset program (from
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/ or the Debian
distribution) and customize your video modes.
If you have an old XF86Config laying around, you may want to copy the
example provided at /usr/X11R6/lib/X11/XF86Config.eg into
/etc/XF86Config and then edit the new configuration file.
(written by Geert Uytterhoeven)
If you have a PAL-based Amiga with a true Multisync monitor (like the A1960), try these as starters (they should be typed on one line; they are split up to make the FAQ format correctly):
ModeLine "vga70" 28.376 640 736 848 912 400 412 414 449 +VSync +CSync
ModeLine "vga" 28.376 640 736 848 912 480 489 491 521
ModeLine "832x624" 28.376 832 940 1020 1024 624 628 630 660 Interlace
+HSync +VSync
ModeLine "832x600" 28.376 832 964 1044 1096 600 600 602 636 Interlace
+HSync -VSync
ModeLine "896x672" 28.376 896 1044 1108 1160 672 676 678 708 Interlace
-HSync +VSync -CSync
ModeLine "960x720" 28.376 960 1132 1172 1224 720 720 722 754 Interlace
-HSync -VSync -CSync
ModeLine "1024x768" 28.376 1024 1196 1212 1288 768 772 774 804
Interlace -HSync +VSync -CSync
For NTSC, you can try replacing 28.376 with 28.636 (but this hasn't been tested). Note that each ModeLine should be entered on one line in your XF86Config file.
(written by Geert Uytterhoeven)
You can create the frame buffer special device nodes for the Amiga using the following commands:
mknod /dev/fb0 c 29 0
mknod /dev/fb0current c 29 0
mknod /dev/fb0autodetect c 29 1
mknod /dev/fb0ntsc c 29 2
mknod /dev/fb0ntsc-lace c 29 3
mknod /dev/fb0pal c 29 4
mknod /dev/fb0pal-lace c 29 5
mknod /dev/fb0multiscan c 29 6
mknod /dev/fb0multiscan-lace c 29 7
mknod /dev/fb0a2024-10 c 29 8
mknod /dev/fb0a2024-15 c 29 9
mknod /dev/fb0euro36 c 29 0
mknod /dev/fb0euro36-lace c 29 11
mknod /dev/fb0euro72 c 29 12
mknod /dev/fb0euro72-lace c 29 13
mknod /dev/fb0super72 c 29 14
mknod /dev/fb0super72-lace c 29 15
mknod /dev/fb0dblntsc c 29 16
mknod /dev/fb0dblntsc-ff c 29 17
mknod /dev/fb0dblntsc-lace c 29 18
mknod /dev/fb0dblpal c 29 19
mknod /dev/fb0dblpal-ff c 29 20
mknod /dev/fb0dblpal-lace c 29 21
mknod /dev/fb0vga c 29 22
mknod /dev/fb0vga70 c 29 23
mknod /dev/fb0user0 c 29 24
mknod /dev/fb0user1 c 29 25
mknod /dev/fb0user2 c 29 26
mknod /dev/fb0user3 c 29 27
mknod /dev/fb0user4 c 29 28
mknod /dev/fb0user5 c 29 29
mknod /dev/fb0user6 c 29 30
mknod /dev/fb0user7 c 29 31
However, these should be pre-created when you install your distribution.
(written by Haidinger Walter)
Before trying to run X, you should edit /etc/XF86Config. Look
for the Monitor section. Set the "HorizSync" and
"VertRefresh" values to the specifications matching your monitor.
That is, e.g. for the M1438S only:
HorizSync 15-40
VertRefresh 45-90
Do a "man XF86Config" for a detailed description.
Of course, this provides neither a warranty nor an insurance that you cannot damage your monitor, but it will be much more difficult now...
(Maintainer's note: I fried my monitor once by blindly copying someone's HorizSync and VertRefresh values. Make certain that you are using the correct values for YOUR monitor; they should be in the book that came with it. And if your monitor starts acting funny, switch it off immediately!: if I had switched mine off, I could have saved myself a $100 US repair bill.)
There is a minor bug in the released 2.0.33 source tree that breaks framebuffer access. There is a patch at James Troup's Linux/m68k pages; it is also available at the Linux/m68k FTP mirrors.
This problem was fixed in the 2.0.33pl1 release.
This is usually because Jes doesn't have the time to test every single configuration before releasing the kernel sources. Monitor the Linux/m68k kernel mailing list for patches (usually all the major fixes have been posted after about two days).
In addition, James Troup maintains a set of pages with the latest patches and release announcements at http://thor.lib.chalmers.se/linuxm68k/.
(written by Geert Uytterhoeven)
This bug apparently appeared in kernel 2.1.15. Geert says:
Gadi Oxman (the IDE guru) told me this could be due to buggy IDE interfaces, IDE drives or both (or a bug in the driver, of course :-), and he suggested to try "ide0=noautotune" which solved my problem last Thursday. But I can't be 100% sure this really solved it...
More recent work has apparently resolved a lot of the IDE bugs people were seeing; try kernel 2.1.119 or later and see if that will fix the problem.
(written by Christian Steigies)
You will need the "loadkeys" command, it is part of the kbd package.
kbd is maintained by Andries E. Brouwer <aeb@cwi.nl> and you can find it at
ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/ and
ftp://ftp.win.tue.nl/pub/linux/util/. The current version is
0.93.
On the SuSE aktuell (March 1997) an older version is on CD 2 as
/kernel/kbd-0.92.tar.gz
Install kbd (gunzip and untar the archive, preferably in
/usr/local/src, then "make") and "make install". If you use
version 0.92 (or lower?) you need to remove resizeicons from the
Makefile). You will then have all the executables in the right place
and a whole lot of keymaps in /usr/lib/kbd/keytables/
As of version 0.93 these keytables are more or less useless for m68k users, since they are for PC-style keyboards. Loading one of these on an Amiga or Atari screws up the keyboard layout so that its virtually unusable. Later versions include some Amiga and Atari keymaps you can work from.
You need to make one by yourself or get one from
ftp://ftp.uni-erlangen.de/pub/Linux/680x0/bin/system/keymaps/,
where Roman Hodek has started collecting Amiga and Atari keymaps. Get
the keymap you want to install, say de-amiga.map, and put it in
/usr/lib/kbd/keytables/ (In newer kbd versions, hopefully
m68k keymaps will also be included.)
Typing "loadkeys de-amiga" will then load this keymap.
To load this keymap during boot, create a rc.loadkeys in /etc/rc.d
like (don't include the lines starting with ---):
--- rc.loadkeys ---
#! /bin/sh
#
# rc.loadkeys load German keyboard map
#
# Version: @(#)/etc/rc.d/rc.loadkeys
#
loadkeys de-amiga
--- rc.loadkeys ---
Debian/m68k has a more automated way of handling the keymaps (through
the kbd Debian package). The package includes several Amiga and
Atari keymaps for various layouts.
(written by Christian Steigies)
The "showkey" command (part of kbd) will tell you which scancode is
generated for every key you press, just write down what you want to be
generated by this key ;-)
The easiest way is to get a keymap for your computer and only change the keys you want to be mapped differently. "dumpkeys" shows you the current keyboard mapping, "dumpkeys -l" will show you all the names of the symbols that can be mapped to the keyboard. "man keytables" tells more about creating keytables.
When you have made a keymap, contact Roman Hodek <rnhodek@informatik.uni-erlangen.de> so you can upload it.
(written by Christian Steigies and Haidinger Walter)
To type umlauts and more in bash, create an .inputrc in your home
dir with:
--- .inputrc ---
set meta-flag On
set convert-meta Off
set output-meta On
--- .inputrc ---
Within tcsh, you need to use the following procedure:
You need an 8-bit clean tcsh with nls support along with the locale package.
In your tcsh, type "echo $version". It should say something like
tcsh 6.07.02 (Astron) 1996-10-27 (m68k-unknown-linux) options
8b,nls,dl,= al
Only the options are important. It should show at least "8b" and "nls". If not, you need to recompile tcsh, but, AFAIK, the tcsh binary on the Linux/m68k mirrors has both options set.
(written by Haidinger Walter)
To use locale, you need at least libc-5.4.17. I'd recommend to install the lib/libc-5.4.23.bin.tar.gz package if you haven't already. 5.4.23 is a bug-fix release to 5.4.17 and does not introduce new features.
Next, you need the locale database. I know two sources:
suse/a1/localedb.tgz
(usually on CD1) to /
lib/glibc-2.0.2-m68k-linux.bin.tar.gz from
the Linux/m68k mirror also contains a _partial_ locale database. To
unpack just the database, type on one line:
tar -zxvf glibc-2.0.2-m68k-linux.bin.tar.gz
"usr/share/locale/*" "usr/share/i18n/*"
Whether you have the SuSE distribution or not, I strongly recommend that you read the mini-HOWTO 'Locales' at least once. It not only describes how to get, build and install the locale package, but also the system requirements and, most important, the usage of the associated commands and environment variables!
So, just follow the instructions of the 'Locales' mini-HOWTO to setup the locale-package and customize it to your system. Finally, set your environment variables to the appropriate values and put them into your .tcshrc.
If you cannot wait that long, have a look at
/usr/share/i18n/locales. If you're German, try (in tcsh):
setenv LC_ALL de_DE
setenv LC_LANG de_DE
bash users would use:
LC_ALL=de_DE
LC_LANG=de_DE
export LC_ALL LC_LANG
(thanks to Boris Bojic for mentioning this on linux-apus)
You need to disable the X Keyboard Extension; add the following line to your XF86Config file:
XkbDisable
(written by Haidinger Walter)
After installing glibc, run ldconfig. Then type ls -l /usr/lib/libc.so. Is it a symlink to libc.so.6 ? Well, this is not correct for glibc.
Type:
rm /usr/lib/libc.so
echo "GROUP ( libc.so.6 ld.so.1 libc.a )" > /usr/lib/libc.so
Note that if you run ldconfig now, it may issue a warning about libc.so not being a shared library. That is Ok, ignore the warning.
(written by Haidinger Walter)
You are missing the /etc/psdevtab file. Type "touch /etc/psdevtab" (as root) and run ps again.
(written by Haidinger Walter)
It says something about an old/bad ncurses library/header but I have the latest lib/ncurses-1.9.9e.bin.tar.gz from the Linux/m68k mirror!
Get the source of ncurses-4.1.tar.gz. It can be found at ftp://ftp.fu-berlin.de/pub/unix/gnu/. Compile it. You should not have any troubles following the descriptions in the INSTALL file. Be sure to install the header files too.
Next, you can type "ln -sf /usr/include /usr/include/ncurses" since some packages look for the ncurses headers in "/usr/include" while others look in "/usr/include/ncurses".
Get and install the current version of the ncurses3.4-dev package (or ncurses4-dev, if you're using 2.1). If you're using apt (which you probably should be), use:
apt-get -y install ncurses4-dev
(written by Haidinger Walter)
Do a "man 8 mount" and search for a section entitled "THE LOOP DEVICE".
Create the device-nodes if they do not exist yet:
mknod /dev/loop0 b 7 0
mknod /dev/loop1 b 7 1
...
mknod /dev/loop9 b 7 9
More information and examples can be found in:
Note: To use loop devices, you must have a kernel that supports them.
(written by Haidinger Walter)
Assuming that you have read "Documentation/modules.txt" in the kernel sources and you have already installed the correct version of modutils, you should type "modprobe -c | grep -w major-2"
You should get:
alias block-major-2 amiflop
If it shows 'floppy' instead of 'amiflop', then the kernel searches
for a module named 'floppy', which does not exist for Linux/m68k. You
have to add the above line to your /etc/conf.modules to
assign the proper name. This is also true for some other modules. See
the next question for details.
Note: Atari users will want to replace 'amiflop' with 'ataflop'.
The kernel looks for the modules under /lib/modules/. The
modules are referenced by name. However, some of the m68k-specific
modules have different names from their Intel counterparts. Here is an
(incomplete) list:
# file /etc/conf.modules
alias eth0 ariadne # depends on your Ethernet card (or off)
alias block-major-2 amiflop
alias char-major-4 amiga_ser
alias char-major-6 lp_intern
alias char-major-14 dmasound
alias net-pf-3 off # no ax25 module available (yet)
alias net-pf-4 off # if you don't use the ipx module
alias net-pf-5 off # if you don't use the appletalk module
If you have any alias that are missing here, please mail!
Some of these settings may be done automatically by recent versions of
modutils.
If BrandX is the Amiga or Atari, it's because for the most part we've found that once you get past installation, running Linux on both systems is pretty much the same. There are a few machine-dependencies that affect day-to-day use (port assignments and keymaps, for example), but 99% of the time it makes no practical difference what system you run Linux on.
The configuration is fairly easy. Tell the application you are using a bus mouse, and make a soft link from /dev/amigamouse (for Amigas) or /dev/atarimouse (for Ataris) to /dev/mouse.
You may also want to enable 3-button emulation if you only have a two-button mouse.
There is a French translation of this FAQ available at http://www.mygale.org/~atari/Linux68k/Faq/, translated by Christian Jacolot.
If you're interested in translating the FAQ into another language, please let me know and I'll try to point you in the right direction.
You will need a program that can extract gzip-compressed tar archives for your system. Mac users can use recent versions of StuffIt Expander; Windows users should be able to use recent versions of WinZip. There is a program called "Opener" for NeXTs that will also work (which actually calls gzip and tar to work).
There is an Amiga program called "UnTGZ" available from Vapor Software (http://www.vapor.com/software/); I have no idea what the license is for this program (and haven't used it).
Alternatively, you can obtain the GNU gzip and tar programs for your current OS. On Aminet (for Amiga users), you should be able to find these in devel/ade, util/gnu or util/arc. Older copies of these tools are in the "tools" directory at Erlangen and its mirrors.
The Mozilla browser apparently works (at least to a certain extent) with the GNU Lesstif library; this is probably your best bet for a Netscape-like browser on Linux/m68k (after all, Mozilla is a stripped-down version of what will be Netscape Communicator 5.0). See http://www.mozilla.org/. The current development version of Debian includes a Mozilla package.
Note that there is a LinuxPPC version of Netscape available (it's actually called the "MkLinux" version), which apparently works with Linux/APUS.
To resolve these problems, get the latest releases of libc6 and dpkg from the slink distribution. Patching your kernel is unnecessary.
(Thanks to Michael Schmitz for pointing me in the right direction for answering this question)
You can; however, I strongly recommend against doing so. There are various reasons: two of the most important are varying file locations and C library conflicts. I speak from experience that you don't want to mix files (I'm still cleaning up old a.out and libc5 files from my system).
Here's a procedure that should work well for doing an installation from scratch, while keeping your old user files available. This is not well-tested or anything, but should help you get the idea of what you need to do:
/etc/passwd and /etc/group
files (you may need them later). You should also print out your
network configuration information.
home partition with all of your user
directories on it, keep it around. Otherwise, make a tar file of your
home directories tree and copy that somewhere safe (a non-Linux
partition should be fine); make sure you use the "-p" flag with tar
to retain all of the permissions.
home if
you already had one.
/etc/passwd
file to your new system, using your distribution's user adding utility
(for Debian, it's useradd). Set the passwords to each
account (or disable them). If you had any special groups (besides a
users or staff group), you may want to add them as well.
home tree at /home (if it was on a
partition). If you have a tar file of the home tree, figure
out where you're going to put it (/var/home might be a good
choice, although a separate partition would be preferable), untar the
home tree there (again using the "-p" flag), and make a
symlink (if necessary) from /home to the root of your new
home tree.
/home and change
the ownership of the users' files to their new users. For example,
for a user named bob (in a group named users), chmod -R bob.users
/home/bob. If people have interspersed files, you may need to do
a find operation to get the permissions straight (refer to
your old password and group files if necessary).
This outline should at least point you in the right direction; let me know if you have any suggestions for improving these instructions.
libc is the C library; basically, it contains all of the system
functions that most (if not all) programs need to run on Linux. It's
similar to a combination of dos.library and
exec.library on Amigas, but it also contains a lot of things
that are in the C runtime library (like, for example,
ixemul.library or the .lib files included with
SAS/C and other compilers).
libc6 and glibc are the same version of libc; officially, it's version 2 of the GNU C Library (but it's the sixth major version of the Linux C library). You can read more about glibc at the GNU C Library pages.
The major versions of libc for Linux/m68k are:
This procedure depends on the distribution you are using. For Debian/m68k 2.1 (slink), you will need at least the following packages (get the latest versions available):
For a fully functioning X installation, you'll probably want a decent window manager (fvwm2, fvwm95, AfterStep, WindowMaker, icewm...), some more X packages (like xcontrib) and some more fonts.
The Linux/m68k kernel supports a "debug" option on the command line. There are several options for this on the Amiga and on Ataris:
If your computer doesn't have a socket for an MMU or FPU already, you will probably need an accelerator board that includes such a socket, or you will need to replace your current chip with a chip that includes the missing feature (i.e. replace a MC68LC040 with an MC68040).
If you do have a socket (usually for an FPU, although some 68020-based computers will have sockets for both an MMU and FPU), you usually need to get an MMU or FPU that is rated at the same clock speed as your main processor (some boards may allow a different speed if they have multiple clocks).
If you have a 68020 and need an MMU, the 68551 MMU is the only choice. If you have a 68020 or 68030 and need an FPU, there are two choices: the 68881 and 68882; the 68882 has more FPU instructions on-board and is of a newer design, but it will be more expensive.
Most Amiga and Atari mail-order dealers will carry these chips; since these are standard Motorola chips, you don't need to buy them from a dealer for your system. In the U.S., Paxtron is generally acknowledged to be the best source for new chips (particularly if you need Amiga custom chips); you may be able to find used ("pulled") chips elsewhere, including at online auctions and the like. At one time, Amiga International had some surplus 68882 FPU chips for sale as well.